Subject: appnIsIn*AdjCpName and appnIsIn*AdjTgNum objects

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Tue, 3 Sep 96 16:11:12 EDT

While we're working through all the editorial changes coming out of
Randy's IETF review, there's one set of technical changes we should look
at as well.  They pertain to the following four objects in the MIB:

    - appnIsInPsAdjCpName
    - appnIsInPsAdjTgNum
    - appnIsInSsAdjCpName
    - appnIsInSsAdjTgNum

These intermediate-session-related objects provide the adjacent CP name
and the TG number looking towards the primary LU end of a session and
looking towards the secondary LU.  In the course of implementing these
objects, we've uncovered problems when the session connector is at the
boundary between a "regular" session stage and an RTP connection.

Here's a picture of the problematic configuration:

  node(PLU)      NNa           NNb           NNc        node(SLU)

                   <******RTP connection*****>
     <----TG1----> <----TG2----> <----TG3----> <----TG4---->

If we focus on NNa, we know exactly what to return for the two objects
looking towards the PLU:  node(PLU)'s NetId.CpName and TG #1.  Looking
towards the SLU, however, both objects are problematic:

    - appnIsInSsAdjCpName:  the session connector in NNa doesn't know
                            that NNb is the next CP in the SLU
                            direction, and even if it did, that won't
                            help a Management Station trying to
                            retrieve and display the session route,
                            since NNb knows *nothing at all* about the
                            session.
    - appnIsInSsAdjTgNum:   the session connector in NNa doesn't know
                            the next TG in the SLU direction, and as
                            before, even if it did, the information
                            wouldn't be useful to a Management Station.

Proposed solution:  modify the objects in the MIB so that NNa can (1)
indicate that in the SLU direction the next session stage is an RTP
connection, and (2) return the NetId.CpName of the other RTP endpoint
(NNc in this case).

Changes:

1.  Update the descriptions for appnIsInPsAdjCpName appnIsInSsAdjCpName:

   Now: "The primary <secondary> stage adjacent CP name of this session."

   Proposal:   "The primary <secondary> stage adjacent CP name of this
               session.  If the session stage traverses an RTP
               connection, the CP name of the remote RTP endpoint is
               returned."

2.  Update the syntaxes and descriptions for appnIsInPsAdjTgNum
    appnIsInSsAdjTgNum:

   Now:  SYNTAX INTEGER (0..255)
         "The primary <secondary> stage adjacent transmission group (TG)
         number associated with this session."

   Proposal:   SYNTAX INTEGER (0..300)
               "The primary <secondary> stage adjacent transmission group
               (TG) number associated with this session.  If the session
               stage traverses an RTP connection, the value 256 is
               returned."

Obviously the upper bound doesn't have to be 300 here, but we need some
value now outside the range (0..255) of legal TG numbers, and it seems
reasonable to "reserve" a few more while we're at it.

Bill, how do you want to proceed with getting SIG / WG consensus on this
change?  I'd like to include it in the APPN MIB as soon as possible
(certainly before AIW 12), because anyone implementing the MIB, at least
in a product that can be an RTP endpoint, is going to run into this
problem.

Bob Moore, IBM Network Management Architecture

---

From: "Bill Kwan" <[email-masked]>
Date: Tue, 3 Sep 1996 17:02:00 EST5EDT

Bob,

I recommend that we give two weeks for everyone to review this
proposal and give their comments. After that time, I will check if
we have a concensus or if we need more time to discuss it.

Regards,
Bill

> Date:          Tue, 3 Sep 96 16:11:12 EDT
> From:          "R.E. (Robert) Moore (254-4436)" <[email-masked]>
> To:            [email-masked], [email-masked]
> Subject:       appnIsIn*AdjCpName and appnIsIn*AdjTgNum objects

---

From: "jim (j.) cobban" <[email-masked]>
Date: Wed, 4 Sep 1996 10:43:00 -0400

In message "appnIsIn*AdjCpName and appnIsIn*AdjTgNum objects", 
Bob Moore writes:

...
>     <----TG1----> <----TG2----> <----TG3----> <----TG4---->
...
>               stage traverses an RTP connection, the value 256 is

There is certainly nothing new with defining special magic TG numbers, the
architecture is full of them.  However I am uncomfortable with extending the
range.  Furthermore this proposal provides only the ability to follow the
session route.  It does not contribute to diagnosing session problems which
originate in the RTP pipe.

Instead of merely signalling that the stage is carried over RTP, I suggest
that the MIB identify the specific RTP pipe, by NCE and TC
identifiers, which the session stage follows.  This has been done in the APPC
MIB, in fields appcActSessRtpNceId and appcActSessRtpTcid, so adding the
following four fields would permit using the same diagnostic procedures for
both end-point and ISR sessions.

appnIsInPsRtpNceId OBJECT-TYPE
      SYNTAX OCTET STRING (SIZE (0..8))
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
          "The HPR Network Connection Endpoint of the primary session stage."

      ::= { appnIsInEntry ? }

appnIsInPsRtpTcid OBJECT-TYPE
      SYNTAX OCTET STRING (SIZE (0|8))
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
          "The Reliable Transport Protocol (RTP) transport onnection 
	  identifier (TCID) of the primary session stage."

      ::= { appnIsInEntry ? }

appnIsInSsRtpNceId OBJECT-TYPE
      SYNTAX OCTET STRING (SIZE (0..8))
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
          "The HPR Network Connection Endpoint of the secondary session stage."

      ::= { appnIsInEntry ? }

appnIsInSsRtpTcid OBJECT-TYPE
      SYNTAX OCTET STRING (SIZE (0|8))
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
          "The Reliable Transport Protocol (RTP) transport onnection 
	  identifier (TCID) of the secondary session stage."

      ::= { appnIsInEntry ? }

There is some risk in having a value for appnIsInXsAdjTgNum which does not
map to a valid TG in the topology database.  If the TCID value is supplied
then appnIsInXsAdjTgNum could be set to the actual TG number of the hop to
appnIsInXsAdjCpName, which is carried in the RSCV in the BIND.  This value is
no longer meaningful after a path switch, but then to find out what the
actual route is at the moment, you could now look at the RTP table in the HPR
MIB.